The present invention relates to a technique for migrating files to a file server, which performs optimum deployment of files, according to the characteristics of a file system.
Currently, storage devices having various types of performance have been developed, and moreover there may be differences in performance between the volumes which make up a storage device. Generally, volumes whose performance is high are high in price, so that, using them, it is not possible to obtain any very high capacity. On the other hand, volumes whose performance is low are cheap in price, so that, using them, it is possible to obtain a high capacity.
For the purpose of reducing the cost entailed by the storage device and so on, there has been proposed a per se known data management method which is endowed with a so called HSM (Hierarchical Storage Management) function, with which the files are optimally deployed utilizing a plurality of such volumes whose characteristics are different from one another. With such an HSM function, files which are frequently utilized by the file system program are moved to “high speed—high price” volumes, while files which are not utilized very often are moved to “low speed—low price” volumes. Moreover, with such an HSM function, this moving of these files is hidden from the client. By controlling the file storage functions in this manner according to an HSM function, it becomes possible to reduce the costs associated with storage.
In Japanese Patent Document JP-A-2008-15984, there is disclosed a data migration method in which, when partially or completely replacing some system due to deterioration or the like of a file server or of a storage device, a volume to which an HSM function is applied is appropriately migrated. With this data migration method, it is distinguished whether or not a file which is in the first tier storage of the migration source file server is a stub file, and, if it is a stub file, then data is read out from the second tier storage using the address information which is stored in this stub file, and this data is written to the second tier storage of the migration destination file server. And the attribute information which is stored in this stub file on the migration source file server is read in, a stub file is created in the first tier storage of the migration destination file server, and this attribute information is written thereinto. The above processing is performed by utilizing the HSM interface. By using the data migration method disclosed in the above identified Patent Document, it is possible to migrate files from a migration source file server which has an HSM interface to a migration destination file server which maintains a tiered structure, and to migrate these files on the basis of the file deployment rules of the migration source.
With the data migration method disclosed in the above identified Patent Document, if the file server which is the subject of replacement does not support any HSM function, in other words if it is not provided with any HSM interface, then it is not possible to acquire any tier information about the migration source files (such as whether a file is on the first tier, or whether it is on the second tier, or the like). Accordingly, it is not possible to arrange the files of the migration source in an appropriate manner upon the migration destination. Due to this, upon the storage device which is the migration destination, it is necessary to prepare a volume which has a capacity equal to the total amount of data stored upon the storage device which is the migration source. But preparation of such a volume using high priced storage is contrary to the spirit of HSM. Although it would also be acceptable to prepare this type of volume using low priced storage, in this case, files which are frequently used come to be arranged upon the new volume in a manner such that the performance directly after migration is unsatisfactory. Moreover, if all of the files are (undesirably) migrated to a single tier, then the performance may decrease very sharply, since there is a possibility that, for files which have not been deployed to an appropriate tier, moving between tiers will occur very frequently directly after migration.